我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。
我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。
前面幾篇花了不少時間研究 FDE，也整理了 AI Coding、AI Agent，以及企業內部自行開發系統對軟體服務商的影響。回到這個系列一開始想討論的問題，我目前的結論是，客戶應該不會單純因為服務商採用 FDE 模式，就願意支付更高的費用。
對企業而言，購買一套軟體或投資 AI，本質上仍然是一項投資決策。企業今天投入一筆成本，是希望在未來某個時間點，能夠透過這套系統創造更大的價值。至於服務商採用什麼開發方法，可能影響客戶對交付能力的信任，但最後仍然需要回到這項投資究竟能帶來多少效益。
不過，這也讓我開始重新思考 FDE 對資訊服務商的意義。如果客戶不會單純為了 FDE 模式付更多錢，那麼投入 FDE 的價值，可能需要從交付效率、專案成功的機會，以及能否持續累積可以重複使用的能力來評估。
最近我花了一些時間研究 Palantir 的產品與 FDE 工作方式，發現它的產品架構及經營方法，正好提供了一個值得參考的方向。
如果將企業購買軟體的決策簡化，我認為可以理解成一個投資關係。企業現在投入 X 的資金，期待未來能夠獲得 Y 的價值。當決策者認為這項投資可能創造更高的價值，而且有足夠的機會實現，就可能願意投入更高的預算。不過，這裡的 Y 並不一定直接反映在營收或成本上。
以我比較熟悉的製造業為例，如果企業希望改善業務部門的工作效率，可能是為了讓業務人員接觸更多潛在客戶，或是更精準地篩選商機，減少花在低價值工作上的時間。
例如原本業務人員每天需要花費大量時間處理詢價與報價，如果能夠透過系統自動取得產品資料、計算價格，並整理成報價單，就有機會在相同人力下處理更多商機。這樣的改善可能降低人工作業成本，也可能讓業務人員有更多時間接觸客戶，進而增加營收。
如果將軟體應用在製造流程，企業可能希望提高自動化程度、減少人工操作、提升產能，或是縮短從接單到出貨的交期，甚至進一步讓短交期變成業務談判的籌碼。有些企業則更在意設備故障、品質異常及客訴問題，希望透過資料整合與流程追蹤，在問題發生時，可以快速找出受到影響的產品，以及可能出問題的製程。
另外，有些投資是為了降低營運風險。例如企業可能希望強化內部稽核、權限管理或產品追溯能力，以符合內控要求或 ISO 等管理制度。這些投資不一定立即增加營收，但如果可以降低錯誤發生的機率、減少營運中斷，或讓企業更容易掌握異常情況，仍然具有相當重要的價值。
還有一種情況，是企業希望為未來的新產品或新市場做準備。例如投入資料平台、AI 模型或研發系統，短期內可能還沒有明確的財務回報，但企業相信這些能力可以讓未來的新產品開發更快，或是有機會進入原本無法服務的市場。
因此，我認為企業投資 AI 與軟體的目的，大致可以從增加營收、降低成本、提升效率、控制風險，以及建立未來發展能力等方向理解。這些目的可能同時存在，也不一定能立即換算成財務數字，但最後都會影響決策者認為這套系統值得投入多少錢。企業是否願意支付更高的費用，和服務商採用哪一種開發方法，並沒有直接的關係。
潛在價值與實際能夠實現的價值
不過，企業相信一套系統具有很高的潛在價值，並不代表一定願意投入相同規模的預算。例如某間工廠希望導入 AI 排程系統，如果能夠更有效地分配機台與生產資源，理論上可能縮短交期、提高設備利用率，甚至增加可以承接的訂單數量。
這些成果如果真的發生，可能具有很高的價值。但企業仍然需要考慮現場資料是否完整、現有流程是否能配合、使用者是否願意採納排程建議，以及系統是否能夠穩定運作。如果上述條件存在太多不確定性，企業即使認同這套系統的潛在效益，也可能不願意一次投入大量預算。
因此，我認為可以將企業的投資評估分成兩個部分。一個是系統成功之後，最多可能創造多少價值，也就是這項投資的潛在價值上限；另一個則是企業相信這些價值有多大的機會真正實現。
這裡還需要考慮投入成本、實現成果需要的時間，以及系統導入可能帶來的風險。對決策者來說，這些條件都會影響最終願意支付的價格。從這個角度來看，FDE 確實可能發揮一些作用。
當工程師能夠更深入了解企業現場，透過實際操作及小範圍驗證，提早發現原本沒有考慮到的問題，就可能降低正式導入後才發現需求不符的風險。如果 FDE 能將需求確認與工程實作更緊密地結合，也可能縮短整體 Lead Time，讓企業更早開始使用系統。
這些改變可能讓客戶更有信心，相信原本預期的效益有機會實現。但我認為客戶願意付費的理由，仍然來自這些交付結果與風險改善。如果服務商無法說明具體能改善哪些問題，客戶也沒有充分理由只因為採用了 FDE 模式，就接受更高的報價。
在研究 OpenAI、Anthropic 與 Palantir 的 FDE 策略時，我原本比較關注這些公司如何安排工程師進入客戶現場，以及為什麼願意投入這麼多資源。但進一步研究 Palantir 的產品架構後，我認為應該先理解它究竟提供了什麼樣的軟體能力，再回頭討論 FDE 在其中扮演的角色。
Palantir 的主要產品包含 Foundry、AIP 與 Apollo，分別涵蓋企業資料與應用、AI，以及軟體部署和管理等能力。這些產品共同構成一套可以持續擴充的企業軟體平台，讓不同企業根據自己的營運需求，建立不同的應用程式與決策流程。
其中一個很重要的概念是 Ontology。如果用比較容易理解的方式說明，Ontology 可以讓企業將原本分散在不同系統中的資料，整理成具有實際業務意義的概念，並且進一步連結企業的判斷規則、操作流程與權限管理。
例如一家製造業可能同時使用 ERP、MES、CRM，以及不同的生產或設備管理系統。這些系統各自保存訂單、工單、庫存、設備或客戶資料，但當企業需要做出跨部門決策時，往往需要先將這些資訊整合起來。
假設某種原料即將短缺，企業可能需要知道哪些訂單受到影響、目前有哪些可用庫存、是否能調整生產順序，以及採取不同方案可能造成多少交期延遲。
這時候，如果系統能夠理解訂單、工單、產品、原料與生產資源之間的關係，就有機會協助企業評估不同的處理方式，再將確認後的決策轉換成實際操作。
Palantir 官方在介紹 Ontology 時，也使用了類似的供應鏈中斷情境，說明如何將資料、判斷邏輯、操作及權限整合，讓人員與 AI Agent 可以在相同的營運脈絡下工作。（參考：Palantir — Why create an Ontology?）
這套架構很強大的地方，是讓企業有機會在同一個平台上，持續建立不同的應用。不同工廠可能有不同的設備、材料及生產流程，對於排程或庫存的管理規則也可能不同。但資料整合、權限管理、應用程式開發及系統部署等能力，仍然可以建立在相同的平台上。
因此，當 Palantir 進入一家新企業時，可以利用既有的平台能力，再根據這間企業的資料、流程與業務規則，建立對應的應用程式。這樣的設計，讓不同客戶的客製化需求有機會共用部分技術架構，而不需要每次都從頭開發所有的基礎功能。
Palantir 在官方架構文件中，也提到希望企業能夠利用共通平台，依照自己的獨特條件，創造差異化的營運成果。它使用投資領域中的 Alpha 來描述這種價值。（參考：Palantir — AIP, Foundry, and Apollo）
這讓我認為，企業投資 Palantir，主要仍然是期待這套軟體能夠協助自己處理重要的營運問題，並且持續建立新的應用能力。至於 FDE，則是讓這套產品更貼近企業現場需求的重要工作方式。
當然，我們無法單純根據官方產品文件，證明 Palantir 的價格有多少來自平台能力、多少來自 FDE 的服務，也不能直接判斷每個客戶的購買動機。不過，從其產品設計可以看到，Palantir 已經將大量原本可能需要重複開發的能力，整合成一套可以持續擴充的軟體架構。
另一個我認為討論 FDE 一定要再三思考的地方，是 Palantir 如何看待 FDE 與產品開發之間的關係。Palantir 在官方架構文件中，將 Forward Deployed Engineering 描述成一種產品開發方法，並且使用 Human Backpropagation 來形容這套機制。
如果借用機器學習的概念，Backpropagation 是透過計算誤差，逐步調整模型內部的參數，讓模型在後續的任務中得到改善。
Palantir 將這個概念用在產品開發上。FDE 深入客戶現場，實際接觸企業的營運問題，再和核心產品工程團隊合作，將現場發現的需求與限制，持續回饋到產品功能與架構的改善。（參考：Palantir — Architecture Center）
所以關鍵是，FDE 完成一個專案後，究竟應該留下什麼。假設 FDE 在某家製造業客戶發現，既有平台缺少一種特定的資料整合方式，因此需要額外開發功能。當未來其他客戶也遇到相同的問題時，Palantir 就可以評估是否將這項能力加入共通平台，讓後續專案直接使用。
當然，並非每個客戶提出的需求都值得變成產品功能。有些需求可能只適用於特定工廠或特殊流程，仍然需要保留客製化的空間。但如果能夠持續辨識不同客戶之間反覆出現的問題，原本需要個別開發的功能，就有機會逐漸成為共通產品的一部分。
Palantir 也提供將資料處理流程、應用程式、模型及部分業務功能封裝成可安裝產品的機制，並透過版本管理與更新機制，讓這些能力可以在不同環境中使用。（參考：Palantir — Foundry DevOps）
這樣的做法，讓 FDE 對 Palantir 可能同時具有兩種價值。
不過，官方文件並沒有提供足夠資訊，讓我們量化 Palantir 究竟有多少客製化需求成功轉換成共通功能，也無法直接計算這套方法節省了多少專案成本。
但從架構與產品開發方式來看，它至少提供了一個值得參考的方向。FDE 在完成當前客戶的專案時，也可以持續整理哪些問題在不同企業之間反覆出現，並評估是否值得將這些能力加入共通產品。這絕對是 FDE 對資訊服務商具有長期價值的原因之一。
從 2021 年開始提供技術顧問服務以來，我接觸過製造、印刷、餐飲等不同產業。這些企業的營運流程、既有系統與管理方式存在不少差異，因此每次開始新的專案，仍然需要花時間理解客戶實際遇到的問題。即使已經累積了不少跨產業經驗，也不代表能夠直接將前一個客戶的系統套用到下一個客戶身上。
例如之前參與印刷業的報價與 CRM 專案，客戶希望將詢價、報價與成本計算流程整合到同一套系統。實際討論後發現，標準品項可以依照既有的價格資料處理，部分超出級距的規格可以透過公式估算，但如果超過設備或材料限制，就需要轉由採購詢價或外發報價。此外，系統還需要保留詢價結果、成本、歷史報價，以及後續調整紀錄。這些工作除了開發報價功能，也需要理解企業如何計算成本、判斷特殊規格，以及不同部門如何共同完成報價流程。
如果未來遇到另一家印刷業客戶，同樣希望改善報價效率，我認為前面累積的經驗具有參考價值，但不一定能直接複製原本的程式碼。因為不同工廠可能採用不同的設備、製程、材料與計價方式，原本的報價公式也未必適用。
不過，需求訪談時需要確認的問題，可能具有相當高的重複性。例如哪些品項具有標準價格、哪些規格可以公式估算、哪些情況需要人工詢價，以及報價完成後是否需要保留調整與核准紀錄。這些問題可以逐漸整理成共通的訪談架構、Decision Table，以及系統驗收時需要確認的條件。
同樣地，之前參與 ERP 導入時，我也遇過請購與採購的審核流程、料號應該合併或拆分，以及備註欄如何承接跨部門資訊等問題。這些經驗讓我在下次進行需求訪談時，可以更早辨識哪些地方需要企業做出業務決定，避免等到系統完成後，才發現原本的流程仍然存在不同理解。
因此，我開始認為 FDE 可以累積的能力，除了程式碼或軟體模組，也包含需求訪談的方法、常見的業務決策、驗收條件，以及系統架構的設計原則。在技術方面，資料整合、API、身分驗證、權限、自動化測試與部署等共通能力，也可以逐漸整理成標準化的架構與工具。這樣一來，即使不同客戶仍然需要自己的業務規則與操作介面，前期需求探索及部分技術開發，就有機會利用過去累積的能力，降低重複投入的時間。
我認為 Palantir 的做法提供了一個值得參考的方向，但對目前的一人公司來說，也不需要立即建立一套像 Foundry 一樣龐大的共通平台。更實際的做法，可能是先從每個專案中，整理哪些問題曾經重複出現，以及哪些工作在下一次可以減少重新開發的時間。
回到這個系列最初的問題，我認為還需要區分客戶的購買價格，以及服務商的交付成本。當企業決定投資一套系統時，主要還是根據預期效益、實現機率與風險，判斷願意投入多少預算。但對服務商而言，如果能夠透過 FDE 更快理解需求，再搭配 AI Coding 與共通技術架構，提高開發效率，原本需要投入的交付成本就有機會下降。
例如過去需要投入三個月完成的專案，如果未來能利用已經建立的工程規範、技術模組與需求訪談方法，在更短時間內完成相同品質的交付，即使客戶支付的費用沒有增加，服務商仍然可能獲得更好的專案利潤。當然，這也需要考慮後續維護、共通模組更新及客製化調整的成本。
而且隨著 AI Coding 普及，市場可能也會逐漸要求軟體開發的價格下降。因此，能夠降低交付成本，不代表服務商就能維持原本的報價。但如果服務商降低成本的幅度高於市場價格下降的幅度，仍然有機會改善經營成果。
從客戶的角度，FDE 如果可以提高系統符合需求的程度、縮短交付時間，並降低導入失敗的風險，就可能讓原本的軟體投資更有機會產生預期成果。從服務商的角度，如果每次專案都能累積共通的工程方法、技術架構與產品能力，未來就可能以更低的成本，交付相同或更好的成果。
這兩種價值是可以同時存在的，客戶可以觀察系統是否提高營收、降低成本、改善流程或減少風險；服務商則需要進一步衡量每次專案的需求探索時間、開發工時、交付 Lead Time、後續維護成本，以及整體專案毛利。
經過前面幾篇文章的反思，我目前傾向認為，客戶不會單純因為資訊服務商採用 FDE 模式，就願意支付更高的費用。企業投資 AI 與軟體，最終仍然需要衡量這項投資可能帶來多少營運效益，以及這些效益有多大的機會實現。
FDE 可能透過更接近現場的需求探索、快速實作與驗證，提升客戶對交付成果的信心。當這些改善可以具體降低導入風險或提高預期效益時，也可能成為客戶願意投入更多預算的理由。
另一方面，從 Palantir 的產品與 FDE 工作方式來看，我認為資訊服務商也需要將每次專案視為累積能力的機會。當工程師深入企業現場，除了完成當前客戶的需求，也可以持續辨識不同客戶之間反覆出現的問題，並將這些經驗轉換成可以重複使用的工程方法、技術架構與產品功能。
「客戶會為了 FDE 模式而付更多錢嗎？」這系列就總結在這裡了，下一篇我會對本主題的所有題目，做個總結。
有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！
iThome鐵人賽
看影片追技術